在現代 Agent 系統中，Tool 的本質是 Agent 與「環境（Environment）」互動的介面與媒介。函數只是程式碼實現的載體，但 Tool 在語意與架構設計上，涵蓋了遠比普通 Function 更豐富的範式。

1. Tool 是「感知器官（Sensors）」與「執行器（Actuators）」

在控制工程與機器人學中，Agent 需要透過 Sensor 觀察世界，透過 Actuator 改變世界。Tool 就是這兩者的軟體化身：

• 感知型 Tool（Sensors / Observations）：

• 它們不改變外部系統狀態（Stateless / Read-Only）。

• 目的：為 Agent 提供決策所需的數據。

• 範例：get_weather()、query_vector_db()、read_file()、fetch_web_page()。

• 動作型 Tool（Actuators / Actions）：

• 它們會產生副作用（Side Effects），改變現實或系統狀態。

• 目的：代表 Agent 執行現實世界的交付或操作。

• 範例：send_email()、execute_sql_delete()、deploy_container()、purchase_ticket()。

2. Tool 的四種高階形態（Beyond Pure Functions）

如果打破「Tool = 演算法函數」的刻板印象，你會發現 Tool 在 Agent 系統中通常呈現以下四種高階形態：

                      ┌── 1. 人類互動介面 (Human-in-the-Loop)
                      ├── 2. 狀態機與子環境 (Sub-Environment / CLI)
[Agent 的 Tool 箱] ───┼── 3. 程式碼沙盒 (Code Interpreter as Universal Tool)
                      └── 4. 另一個 Agent (Multi-Agent Protocol)

① 人類作為工具（Human-in-the-Loop as a Tool）

Tool 不一定由程式碼自動執行。它可以是一個「掛起並等待人類輸入」的非同步介面。

• 當 Agent 遇到不確定的高風險決策（例如轉帳 100 萬），它可以發出 request_human_approval(reason="...") 的 Tool Call。
• 系統此時暫停 Agent Loop，發送通知給管理員，管理員點擊 UI 批准後，將人類的 Input 當作 Observation 回傳給 Agent 繼續運作。

② 狀態機與子環境（Sub-Environments / Stateful Shells）

許多 Tool 不是「輸入 X，輸出 Y」就結束了，它是一個持久化的互動式環境。

• 範例：SSH Tool 或 Browser DOM Tool。
• 當 Agent 呼叫 click_button(id="submit") 時，它不是在跑一個獨立函數，而是在操控一個保有 Session 狀態的瀏覽器（Puppeteer / Playwright）。下一次呼叫 get_page_content() 時，拿到的是按鈕點擊後的網頁新狀態。

③ 程式碼沙盒（Code Interpreter —— 萬能工具）

如果為每種需求都寫一個 Tool（如 add()、subtract()、plot_chart()），工具庫會無限膨脹。

• Code Interpreter 模式將「寫 Code 並在 Sandbox 中運行」變成單一工具：

# LLM 發出 Tool Call，內容直接是一段 Python 程式碼
execute_python(script="import pandas as pd; df = pd.read_csv('data.csv'); print(df.describe())")

• 此時 Tool 的角色從「具體的 API 介面」躍升為「圖靈完備的通用運算環境」。Agent 可以自己動態撰寫它需要的任何算法工具。

④ 另一個 Agent（Multi-Agent as a Tool）

在 Multi-Agent（多代理）架構中，一個專門負責「網頁搜尋」的 Agent，在主協調 Agent（Orchestrator）眼中，就只是一個可以呼叫的 Tool。

• 主 Agent 呼叫 research_agent.run(topic="2026 晶片產業動態")。
• 內部可能會觸發另一個子 Agent 幾十輪的內部 ReAct Loop，最後只回傳一份精煉的報告給主 Agent。

3. Tool 的元數據（Meta-data）：告訴模型「心智模型」

普通 Function 的參數定義（如 int a, string b）只是給編譯器看的；但 Tool 的定義是給 LLM 的大腦（Reasoning Engine） 看的。

因此，設計 Tool 時，文字描述（Description）與上下文與約束（Constraints）才是 Tool 的靈魂：

{
  "name": "cancel_subscription",
  "description": "【警告：不可逆操作】只有當使用者明確提及 '確定要取消訂閱' 且已過期不可退款時才可使用。呼叫前必須先執行 query_user_plan 確認訂閱狀態。",
  "parameters": { ... }
}

這類描述直接塑造了模型的行為邊界與推理路徑，將商業邏輯與安全護欄（Guardrails）直接融入 Tool 的宣告中。

4. 總結：架構視角的演進